[登壇レポート]「防衛への一歩!AWSアカウントを不正利用から守るための必須防止対策ナビ」というタイトルでDevelopersIO 2023に登壇しました #DevIO2023
こんにちは!AWS事業本部のおつまみです。
みなさん、AWS不正利用対策していますか?
AWSを安全に使うために、不正利用対策は避けては通ることができません。
今回は弊社年1の一大イベントであるDevelopersIO 2023でAWS不正利用対策について登壇したので、その内容を共有します!
登壇動画
登壇資料
前提
セッション概要
今回のセッションの概要は以下のとおりです。
被害総額が膨らむAWSアカウント不正利用。脅威は常にあなたの身近に潜んでいます…。本セッションでは、アクセスキー漏洩やパスワード流出による不正利用から身を守るための防止対策をお伝えします。今日からできる実践的な知識で、あなたが大切にしているAWSアカウントを守り抜く力を身につけましょう!
というわけで、今回はAWSアカウントで不正利用を起こさせないための超初級のセキュリティ対策のお話しです。
セッションのテーマ
セッションのテーマは自身で自分のAWSアカウントを保護し、安全にAWSを使って欲しいという思い理由で選定しました
セッション対象者
- AWSの基本的な概念は知っている方
- AWSを使う上でセキュリティ対策に不安がある方
- そしてAWSアカウントの管理者
セッションのゴール
- AWSアカウントの不正利用による被害を理解する
- 実際に不正利用が起きてしまったときのフローを知っておく
- セッション後、すぐに必須防止対策を実施できるようになる
解説
前半:AWS不正利用について
AWS不正利用とは
AWSアカウントの不正利用とは、第三者がAWSアカウントの認証情報を盗んだり、セキュリティの脆弱性をついてリソースに不正アクセスしたりすることです。
AWSアカウントの不正利用による悪影響
AWSアカウントの不正利用により、このような悪影響があります。
AWS不正利用の具体例
AWS不正利用は下記のようなことが原因で発生しています。
- アクセスキー漏洩
-
IAMユーザーのパスワード流出
-
アプリケーションの脆弱性をついた攻撃
AWS不正利用の被害
AWS不正利用によりこのような被害が起こります。
- 多額の利用費請求
-
情報漏洩
- 攻撃の加害者になる
中盤:AWS不正利用対策の前に
AWS不正利用対策の前をお伝えする前に、突然クイズを出しました..!
みなさん、わかりますか?
.....
............。
答えは「通知」でした!
2か所通知先を設定するのがベストプラクティスです。
後半:AWS不正利用対策について
実際にAWSアカウントで不正利用が起きてしまった場合に取り組むべきことです。
本ブログでは、セッションのメインとなる必須防止対策に絞ってお伝えします。
セキュリティサービスの有効化
これらのサービスは必ず、有効化させましょう!
- CloudTrail
- AWS Config
【Security Hub修復手順】[Config.1] AWS Config を有効にする必要があります | DevelopersIO
- AWS Security Hub
[入門]社内勉強会で AWS Security Hubの話をしました | DevelopersIO
- Amazon GuardDury
【Security Hub修復手順】[GuardDuty.1] GuardDuty を有効にする必要があります | DevelopersIO
IAMの棚卸し・アクセスキー漏洩防止ソリューション導入
ここでは7つの対策ができているか、確認しましょう!
- IAMの概念知っていますか?
- 不安がある方は必ず下記の講座を受講してください。両方合わせて1時間で終わります。
- 不要なIAMユーザー・アクセスキーを管理していませんか?
- 以下が削除基準です。
- 90⽇間以上ログイン・使用されていない
- 退職、異動、⼀時的に作成したものが残っている等で、不要となっている
認証情報レポートで不要なIAMユーザー・アクセスキーを棚卸ししてみた | DevelopersIO
- 以下が削除基準です。
- IAMユーザーのパスワードポリシーは強固ですか?
- 社内のセキュリティポリシーに合わせてパスワードを強固にしましょう。(NISCに準拠する場合、最小文字数は10文字以上)
IAMユーザーのパスワードポリシーを変更して安全性を上げてみた
- 社内のセキュリティポリシーに合わせてパスワードを強固にしましょう。(NISCに準拠する場合、最小文字数は10文字以上)
- IAMユーザーのMFAは有効化されていますか?
- MFA設定は必須です。IAMポリシーを使用し、MFAを使った認証をしていない場合に操作を拒否する設定も行いましょう。
IAMユーザーのMFA(多要素認証)は有効になっていますか?現状を確認→是正→適切な状態を維持するまでの流れを整理してみた | DevelopersIO
- MFA設定は必須です。IAMポリシーを使用し、MFAを使った認証をしていない場合に操作を拒否する設定も行いましょう。
- 不要なIAMロールを管理していませんか?
- 以下が削除基準です。
- 90⽇間以上使用されていない
- ⼀時的に作成したものが残っている等で、不要となっている
AWS IAMリソースの棚卸し方法をまとめてみた | DevelopersIO
- 以下が削除基準です。
- git-secretsは導入されていますか?
- AWSを使った開発に関わる全てのメンバーが導⼊してください。
AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した | DevelopersIO
- AWSを使った開発に関わる全てのメンバーが導⼊してください。
- IAMユーザー・ロールに強力な権限を与えていませんか?
- AdministratorAccess・PowerUserAccessは強固なポリシーです。特定の利用者のみに与えるようにしましょう。
強力な権限を与えているIAMユーザー・ロールをAWS CLIで棚卸してみた | DevelopersIO
- AdministratorAccess・PowerUserAccessは強固なポリシーです。特定の利用者のみに与えるようにしましょう。
Security HubによるAWS環境のセキュリティ状況スコアリング
セキュリティスコアを上げることで、お使いのAWS環境がよりセキュアになります。
スコア100%を目指して、「失敗」している項目への対応を行いましょう!
下記に記載のコントロールが失敗している場合は、修復手順に沿って、修復することを必須としています。
修復必須項目
- 【Security Hub修復手順】[CloudFront.1] CloudFront ディストリビューションでは、デフォルトのルートオブジェクトが設定されている必要があります | DevelopersIO
- 【Security Hub修復手順】[CloudTrail.1] CloudTrail を有効にして、少なくとも 1 つのマルチリージョンの追跡で、読み取りと書き込みの管理イベントを含めた設定をする必要があります | DevelopersIO
- 【Security Hub修復手順】[CodeBuild.1] CodeBuild GitHub または Bitbucket のソースリポジトリの URL は、OAuth を使用する必要があります | DevelopersIO
- 【Security Hub修復手順】[CodeBuild.2] CodeBuild プロジェクト環境変数にクリアテキストの認証情報を含めることはできません | DevelopersIO
- 【Security Hub修復手順】[Config.1] AWS Config を有効にする必要があります | DevelopersIO
- 【Security Hub修復手順】 [EC2.1] Amazon EBS スナップショットはパブリックに復元可能であってはなりません。 | DevelopersIO
- 【Security Hub修復手順】[EC2.2] VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックとアウトバウンドトラフィックを許可しないようにする必要があります | DevelopersIO
- 【Security Hub修復手順】[EC2.16] 未使用のネットワークアクセスコントロールリストを削除する必要があります | DevelopersIO
- 【Security Hub修復手順】[EC2.18] セキュリティグループは、許可されたポートに対して無制限の着信トラフィックのみを許可する必要があります。 | DevelopersIO
- 【Security Hub修復手順】[EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可してはいけません | DevelopersIO
- 【Security Hub修復手順】[ECS.1] Amazon ECS タスク定義には、セキュアなネットワークモードとユーザー定義が必要です | DevelopersIO
- 【Security Hub修復手順】[ECS.2] Amazon ECS サービスには、パブリック IP アドレスを自動で割り当てないでください | DevelopersIO
- 【Security Hub修復手順】[ECS.3] ECS タスクの定義では、ホストのプロセス名前空間を共有しないでください | DevelopersIO
- 【Security Hub修復手順】[ECS.4] ECS コンテナは、非特権として実行する必要があります | DevelopersIO
- 【Security Hub修復手順】[ElasticBeanstalk.2] Elastic Beanstalk のマネージドプラットフォームの更新を有効にする必要があります | DevelopersIO
- 【Security Hub修復手順】[GuardDuty.1] GuardDuty を有効にする必要があります | DevelopersIO
- 【Security Hub修復手順】[IAM.1] IAM ポリシーでは、完全な「*」管理者権限を許可しないでください | DevelopersIO
- 【Security Hub修復手順】[IAM.5] コンソールパスワードを使用するすべての IAM ユーザーに対して MFA を有効にする必要があります | DevelopersIO
- 【Security Hub修復手順】 [IAM.7] IAM ユーザーのパスワードポリシーには強力な設定が必要です | DevelopersIO
- 【Security Hub修復手順】[IAM.8] 未使用の IAM ユーザー認証情報は削除する必要があります | DevelopersIO
- 【Security Hub修復手順】[IAM.21] 作成する IAM カスタマーマネージドポリシーにはサービスのワイルドカードアクションを許可してはいけません | DevelopersIO
- 【Security Hub修復手順】[Lambda.1] Lambda 関数ポリシーでは、パブリックアクセスを禁止する必要があります。 | DevelopersIO
- 【Security Hub修復手順】[Lambda.2] Lambda 関数はサポートされているランタイムを使用する必要があります | DevelopersIO
- 【Security Hub修復手順】[RDS.1] RDS スナップショットはプライベートである必要があります | DevelopersIO
- 【Security Hub修復手順】 [RDS.2] Amazon RDS DB インスタンスはパブリックアクセスを禁止する必要があります。 | DevelopersIO
- 【Security Hub修復手順】[RDS.18] RDS インスタンスは VPC 内にデプロイする必要があります | DevelopersIO
- 【Security Hub修復手順】[PCI.Redshift.1] Amazon Redshift クラスターはパブリックアクセスを禁止する必要があります | DevelopersIO
- 【Security Hub修復手順】[Redshift.7] Amazon Redshift クラスターは拡張 VPC ルーティングを使用する必要があります | DevelopersIO
- 【Security Hub修復手順】[S3.2] S3 バケットではパブリック読み取りアクセスを禁止する必要があります | DevelopersIO
- 【Security Hub修復手順】[S3.3] S3 バケットはパブリック書き込みアクセスを禁止する必要があります | DevelopersIO
- 【Security Hub修復手順】[S3.6] バケットポリシー内で別の AWS アカウントに付与された Amazon S3 許可は制限する必要があります | DevelopersIO
- 【Security Hub修復手順】[S3.8] S3 ブロックパブリックアクセス設定は、バケットレベルで有効にする必要があります | DevelopersIO
- 【Security Hub修復手順】[SSM.4] SSM ドキュメントはパブリックにしないでください | DevelopersIO]
GuardDutyによる脅威検知の暫定体制づくり
GuardDuty通知の有効化
- GuardDutyを有効化しただけでは、脅威を検出した際に通知を受け取ることができません。通知設定も合わせて行いましょう。
AWS環境に潜む脅威をAmazon GuardDutyで検知してみた
GuardDutyで脅威検知した際の対応について
- 基本方針
- 脅威検知した内容については基本的に全て対応するようにしてください(既に攻撃を受けているアカウントであるため、再度攻撃を受ける可能性が高いです。そのため検知した脅威については例え ”重要度[低]” であっても全て対応するという姿勢が基本になります)
Amazon GuardDuty ユーザーガイド
- 脅威検知した内容については基本的に全て対応するようにしてください(既に攻撃を受けているアカウントであるため、再度攻撃を受ける可能性が高いです。そのため検知した脅威については例え ”重要度[低]” であっても全て対応するという姿勢が基本になります)
GuardDuty通知が多すぎて運用ができないとき
- 基本方針
- 前項「GuardDutyで脅威検知した際の対応について」で述べた通り、検知したものは全て対応することを基本方針としてください。しかし、GuardDutyで検知するものの中にはシステム上必要な設定・措置に対して、通知されるケースもあるため、そういったものを後述の抑制ルールを使用して抑制していきます。
GuardDutyの抑制ルールを活用してセキュリティ検知のノイズを減らす
- 前項「GuardDutyで脅威検知した際の対応について」で述べた通り、検知したものは全て対応することを基本方針としてください。しかし、GuardDutyで検知するものの中にはシステム上必要な設定・措置に対して、通知されるケースもあるため、そういったものを後述の抑制ルールを使用して抑制していきます。
まとめ
これで不正利用に遭うリスクを最小限にできたはずです...!
さいごに
今回は当日来れなかった方々のためにも、改めてブログで内容をまとめてみました。
この登壇をインプットとして、1人でも多くの方々がお使いのAWS環境を見直すきっかけ(=行動)を作り出せていたら、今回登壇した意味があるなと感じます。
ちなみに今回初の40分間オフライン登壇だったのですが、、、、、私は目覚めてしまいました。
オフライン登壇楽しい!!!!!!!!!!!!!!
今後も登壇できるよう技術を磨いていきたいと思います。
以上、おつまみ(@AWS11077)でした!